On Fedora and Arch the libtorrent Python binding is installed as a system package built for the distro's default interpreter (python3 = 3.14 on a fresh 2026 distro), and the venv uses --system-site-packages specifically so import libtorrent resolves against it (see the dnf comment at lines 83-87 and the venv branch at 1055-1058). This hotfix now forces the venv to be built with PYBIN=python3.13 (pick_python prefers <3.14). A 3.13 venv with --system-site-packages inherits the 3.13 site-packages tree, not 3.14's, and a CPython C-extension such as libtorrent built against the 3.14 ABI cannot be imported under 3.13 anyway. The net effect is that the litellm fix likely re-breaks import libtorrent on Fedora/Arch — the very case the system-site-packages branch exists to handle. The comment at lines 1055-1056 ("inherit site-packages so import libtorrent resolves") is no longer accurate when PYBIN differs from the system python. Consider installing/building the libtorrent binding for the selected 3.13 interpreter (e.g. pip/system 3.13 binding), or documenting that torrent ingest is unavailable on these distros until a 3.13-compatible binding is present.

Document the interpreter-mismatch caveat; ideally also ensure a 3.13 libtorrent binding is available.:

# NOTE: --system-site-packages only helps when the venv interpreter matches
# the interpreter the system libtorrent binding was built for. On a distro
# whose default python3 is 3.14, a 3.13 venv will NOT see (or be able to
# load) the 3.14-built binding, so torrent ingest may be unavailable until
# a 3.13-compatible libtorrent binding is installed.
if command -v pacman >/dev/null 2>&1 || [[ -f /etc/fedora-release ]]; then
    "$PYBIN" -m venv --system-site-packages .venv
else
    "$PYBIN" -m venv .venv
fi

_{Was this helpful? React with 👍 / 👎}

The auto-install fallback runs sudo pacman -S --noconfirm python313 on Arch. Arch's official repositories ship a single rolling python package (currently 3.14) and do not provide a versioned python313 package (older interpreters live in the AUR). This command will fail; because it is guarded by || true, the subsequent pick_python will still find nothing and the script dies with the manual-install message. The auto-install path is therefore effectively a no-op on Arch — acceptable as a graceful fallback, but the package name is misleading and could be replaced or removed to avoid implying Arch auto-install works.

Drop the bogus python313 pacman install and rely on the die() guidance.:

elif command -v pacman >/dev/null 2>&1; then
    # Arch ships only the rolling `python`; no official versioned
    # package exists, so we cannot auto-install 3.13 here. Fall through
    # to the clear die() message (uv venv --python 3.13 or AUR).
    :
fi

_{Was this helpful? React with 👍 / 👎}

🏁 Script executed:

# Check if the file exists and examine the surrounding context
file="scripts/install-server.sh"
if [ -f "$file" ]; then
  echo "=== File exists ==="
  wc -l "$file"
  echo "=== Lines 1040-1060 ==="
  sed -n '1040,1060p' "$file"
else
  echo "File not found at $file"
  # Try to find it
  find . -name "install-server.sh" 2>/dev/null
fi

Repository: jaylfc/taOS

Length of output: 871

🌐 Web query:

curl pipe sh security risks arbitrary code execution

💡 Result:

The practice of piping the output of a remote command like curl or wget directly into a shell interpreter (e.g., | sh or | bash) is widely considered a significant security risk and a poor technical practice [1][2][3][4]. The primary dangers include arbitrary code execution and the bypass of critical security and integrity checks [2][4]. The core risks include: Arbitrary Code Execution: The command immediately executes code from a remote source with the privileges of the user running the shell [2][4]. If the command is run with sudo, it grants root-level access to the remote script, which can result in full system compromise [1][5]. Lack of Integrity Verification: This method bypasses the ability to inspect the script, verify a cryptographic signature (such as GPG), or check a checksum (like SHA-256) before execution [1][2]. You have no assurance that the content received matches what the publisher intended [1]. Transport and Supply Chain Attacks: Relying solely on HTTPS is insufficient [2]. Any compromise of the server, CDN, DNS, or network path (man-in-the-middle attack) can lead to the silent delivery of malicious payloads [6][2]. Failure Modes and Partial Execution: Bash does not necessarily wait for the entire script to download before beginning execution [4]. If the connection is severed mid-stream, the shell may execute a partial, truncated, or malformed script, which can lead to unpredictable behavior, such as unintended file deletions [3][7][4]. Detection of Transport Method: A malicious server can detect that a script is being piped into a shell (versus being saved to a file) by observing timing and TCP behavior, allowing it to serve a clean script to users who save the file but a malicious one to those who pipe it [1][8]. Best Practices: The recommended alternative is to separate the download, verification, and execution steps [2][7][5]: 1. Download: Fetch the script to a local file (e.g., curl -sSL https://example.com/install.sh -o install.sh) [2][4][8]. 2. Verify: Inspect the script content manually or use verification tools to check the file against a known-good checksum or GPG signature provided through a separate, trusted channel [2][4][5]. 3. Execute: Only after verifying the integrity of the downloaded file should you run it (e.g., bash./install.sh) [2][5][8]. If you must use automation, consider caching the script, pinning it to a specific versioned URL, or using a proper package manager that natively handles signatures and integrity validation [4][9].

Citations:

• 1: https://security.stackexchange.com/questions/213401/is-curl-something-sudo-bash-a-reasonably-safe-installation-method
• 2: https://docs.cli.vulnetix.com/docs/sast-rules/vnx-bash-002/
• 3: https://www.seancassidy.me/dont-pipe-to-your-shell.html
• 4: https://tferdinand.net/en/why-curl-bash-is-a-dangerous-bad-habit/
• 5: https://unix.stackexchange.com/questions/506468/what-is-the-best-next-step-when-faced-with-curl-url-sh
• 6: https://spin.atomicobject.com/security-spectrum-curl-sh/
• 7: https://lwn.net/Articles/890343/
• 8: https://stackoverflow.com/questions/56881266/how-the-alternatives-are-better-than-using-curl-sudo-sh
• 9: https://www.chef.io/blog/5-ways-to-deal-with-the-install-sh-curl-pipe-bash-problem

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.